Skip to content

feat(extension): channel-flip guard for the chat session DB - #295

Draft
aarontrowbridge wants to merge 1 commit into
mainfrom
fix/server-db-channel-guard
Draft

feat(extension): channel-flip guard for the chat session DB#295
aarontrowbridge wants to merge 1 commit into
mainfrom
fix/server-db-channel-guard

Conversation

@aarontrowbridge

Copy link
Copy Markdown
Member

Motivation

2026-08-08 fleet incident: the extension update refreshed the vendored opencode binary, swapping a dev-channel build for a local-channel one. opencode picks its chat DB by build channel (devopencode-dev.db, unbranded/local → opencode-local.db), so launchd restarted a healthy server on a fresh, empty database — every fleet panel showed an empty history while the 650-session opencode-dev.db sat untouched on disk. Diagnosis required reading minified bundle strings; total silent-failure window was hours.

What this does

Two never-blocking additions to ServerManager:

  1. Provenance log line — the spawned binary's sha256 goes to the output channel at start, so the next post-mortem starts with "which binary was it" already answered (complements feat(extension): build provenance stamping for verifiable binaries #292's provenance stamping).
  2. warnIfServingFreshDb — after the health probe, if /session?limit=1000 serves < 10 sessions while a sibling opencode-*.db on disk exceeds 32 MB, the extension appends a WARNING and toasts with an "Open Output" action. The silent-empty-panel symptom becomes an explicit, actionable error.

False-positive analysis

  • Fresh install → no large sibling DB → silent.
  • A fork serving its own large DB → high session count → silent.
  • Client riding the SSH tunnel → serves the canonical count through the tunnel → silent (the disk scan runs client-side, but the count check gates first).
  • Any probe failure → silent by construction (fire-and-forget, .catch(() => {})).

Validation

  • tsc --noEmit clean.
  • vitest: 905 passed; the 3 failures in test/server_auth.test.ts (buildServerSpawnEnv key-exactness) reproduce identically on unmodified main (0944b3b) — pre-existing, unrelated. Worth its own issue.

Follow-ups (not in this PR)

opencode resolves its chat DB by build channel (dev -> opencode-dev.db,
unbranded/local -> opencode-local.db, ...). A vendored-binary refresh can
therefore boot a HEALTHY server on a FRESH database: panels show an empty
history while the real one sits untouched on disk (fleet incident
2026-08-08, diagnosed by hand over hours).

Two cheap, never-blocking additions to ServerManager:

- log the spawned binary's sha256 at start (provenance for post-mortems,
  complements #292)
- warnIfServingFreshDb: after health, if /session serves < 10 sessions
  while a sibling opencode-*.db on disk exceeds 32 MB, append a WARNING
  to the output channel and toast with an 'Open Output' action

False-positive analysis: fresh installs have no large sibling DB (silent);
a fork serving its own large DB serves a high session count (silent); the
client-tunnel path serves the canonical count through the tunnel (silent).
Any probe failure is silent by construction.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant